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Abstract 
This document describes the IESG’s procedures for handling documents 
submitted for RFC publication via the RFC Editor, subsequent to the 
changes proposed by the IESG at the Seoul IETF, March 2004. 
This document updates procedures described in RFC 2026 and RFC 3710. 
1. Introduction and History 
There are a number of different methods by which an RFC is published, 
some of which include review in the Internet Engineering Task Force 
(IETF), and some of which include approval by the Internet 
Engineering Steering Group (IESG): 


o IETF Working Group (WG) to Standards Track: Includes WG consensus, 
review in the IETF, IETF Last Call, and IESG approval 


o IETF WG to Experimental/Informational: Includes WG consensus, 
review in the IETF, and IESG approval 


o Area Director (AD) sponsored to Standards Track: Includes review 
in the IETF, IETF Last Call, and IESG approval 


o AD Sponsored Individual to Experimental/Informational: Includes 
some form of review in the IETF and IESG approval 


o Documents for which special rules exist 
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o RFC Editor documents to Experimental/Informational 


This memo is only concerned with the IESG processing of the last 
category. 


Special rules apply to some documents, including documents from the 
Internet Architecture Board (IAB), April 1st RFCs, and republication 
of documents from other standards development organizations. The 
IESG and the RFC Editor keep a running dialogue, in consultation with 
the IAB, on these other documents and their classification, but they 
are outside the scope of this memo. 


For the last few years, the IESG has reviewed all RFC Editor 
documents (documents submitted by individuals to the RFC Editor for 
RFC publication) before publication. In 2003, this review was often 
a full-scale review of technical content, with the ADs attempting to 
clear points with the authors, stimulate revisions of the documents, 
encourage the authors to contact appropriate working groups and so 
on. This was a considerable drain on the resources of the IESG, and 
since this is not the highest priority task of the IESG members, it 
often resulted in significant delays. 


In March 2004, the IESG decided to make a major change in this review 
model. The new review model will have the IESG take responsibility 
ONLY for checking for conflicts between the work of the IETF and the 
documents submitted; soliciting technical review is deemed to be the 
responsibility of the RFC Editor. If an individual IESG member 
chooses to review the technical content of the document and finds 
issues, that member will communicate these issues to the RFC Editor, 
and they will be treated the same way as comments on the documents 
from other sources. 


Note: This document describes only the review process done by the 
IESG when the RFC Editor requests that review. There are many other 
interactions between document editors and the IESG for instance, an 
AD may suggest that an author submit a document as input for work 
within the IETF rather than to the RFC Editor, or the IESG may 
suggest that a document submitted to the IETF is better suited for 
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ubmission to the RFC Editor but these interactions are not described 
n this memo. 


2. Background Material 
The review of independent submissions by the IESG was prescribed by 


RFC 2026 [1] section 4.2.3. The procedure described in this document 
is compatible with that description. 
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RFC 3710 [4] section 5.2.2 describes the spring 2003 review process 
(even though the RFC was published in 2004); with the publication of 
this document, the procedure described in RFC 3710 is no longer 
relevant to documents submitted via the RFC Editor. 


3. Detailed Description of IESG Review 


The RFC Editor reviews submissions for suitability for publications 
as RFC. Once the RFC Editor thinks a document may be suited for RFC 
publication, the RFC Editor asks the IESG to review the documents for 
conflicts with the IETF standards process or work done in the IETF 
community. 


The review is initiated by a note from the RFC Editor specifying the 
document name, the RFC Editor’s belief about the document’s present 
suitability for publication, and (if possible) the list of people who 
have reviewed the document for the RFC Editor. 


The IESG may return five different responses, any of which may be 
accompanied by an IESG note to be put on the document if the RFC 
Editor wishes to publish. 


1. The IESG has not found any conflict between this document and IETF 
work. 


2. The IESG thinks that this work is related to IETF work done in WG 
<X>, but this does not prevent publishing. 


3. The IESG thinks that publication is harmful to the IETF work done 
in WG <X> and recommends not publishing the document at this time. 


4. The IESG thinks that this document violates IETF procedures for 
<X> and should therefore not be published without IETF review and 
IESG approval. 


5. The IESG thinks that this document extends an IETF protocol ina 
way that requires IETF review and should therefore not be 
published without IETF review and IESG approval. 


The last two responses are included respectively, for the case where 
a document attempts to take actions (such as registering a new URI 
scheme) that require IETF consensus or IESG approval (as these terms 
are defined in RFC 2434 [2]), and for the case where an IETF protocol 
is proposed to be changed or extended in an unanticipated way that 
may be harmful to the normal usage of the protocol, but where the 
protocol documents do not explicitly say that this type of extension 
requires IETF review. 
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If a document requires IETF review, the IESG will offer the author 
the opportunity to ask for publication as an AD-sponsored individual 
document, which is subject to full IESG review, including possible 
assignment to a WG or rejection. Redirection to the full IESG review 
path is not a guarantee that the IESG will accept the work item, or 
even that the IESG will give it any particular priority; it is a 
guarantee that the IESG will consider the document. 


The IESG will normally have review done within 4 weeks from the RFC 
Editor’s notification. In the case of a possible conflict, the IESG 
may contact a WG or a WG chair for an outside opinion of whether 
publishing the document is harmful to the work of the WG and, in the 
case of a possible conflict with an IANA registration procedure, the 
IANA expert for that registry. 


Note that if the IESG has not found any conflict between a submission 
and IETF work, then judging its technical merits, including 
considerations of possible harm to the Internet, will become the 
responsibility of the RFC Editor. The IESG assumes that the RFC 
Editor, in agreement with the IAB, will manage mechanisms for 
additional technical review. 


4. Standard IESG Note 


One of the following IESG notes will be sent to the RFC Editor for 
all documents, with a request for placement either in or immediately 
following the "Status of this Memo" section of the finished RFC, 
unless the IESG decides otherwise: 


1. For documents that specify a protocol or other technology, and 
that have been considered in the IETF at one time: 


The content of this RFC was at one time considered by the IETF, 
and therefore it may resemble a current IETF work in progress or a 
published IETF work. This RFC is not a candidate for any level of 
Internet Standard. The IETF disclaims any knowledge of the 
fitness of this RFC for any purpose and in particular notes that 
the decision to publish is not based on IETF review for such 
things as security, congestion control, or inappropriate 
interaction with deployed protocols. The RFC Editor has chosen to 
publish this document at its discretion. Readers of this RFC 
should exercise caution in evaluating its value for implementation 
and deployment. See RFC 3932 for more information. 
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2. For documents that specify a protocol or similar technology and 
are independent of the IETF process: 


This RFC is not a candidate for any level of Internet Standard. 
The IETF disclaims any knowledge of the fitness of this RFC for 
any purpose and in particular notes that the decision to publish 
is not based on IETF review for such things as security, 
congestion control, or inappropriate interaction with deployed 
protocols. The RFC Editor has chosen to publish this document at 
its discretion. Readers of this document should exercise caution 
in evaluating its value for implementation and deployment. See 
RFC 3932 for more information. 


3. For documents that do not specify a protocol or similar 
technology: 


This RFC is not a candidate for any level of Internet Standard. 
The IETF disclaims any knowledge of the fitness of this RFC for 
any purpose and notes that the decision to publish is not based on 
IETF review apart from IESG review for conflict with IETF work. 
The RFC Editor has chosen to publish this document at its 
discretion. See RFC 3932 for more information. 


5. Examples of Cases Where Publication Is Harmful 


This section gives a couple of examples where delaying or preventing 
publication of a document might be appropriate due to conflict with 
IETF work. It forms part of the background material, not a part of 
the procedure. 


Rejected Alternative Bypass: A WG is working on a solution to a 
problem, and a participant decides to ask for publication of a 
solution that the WG has rejected. Publication of the document will 
give the publishing party an RFC number to refer to before the WG is 
finished. It seems better to have the WG product published first, 
and have the non-adopted document published later, with a clear 
disclaimer note saying that "the IETF technology for this function is 
ATG 


Example: Photuris (RFC 2522), which was published after IKE (RFC 
2409). 


Inappropriate Reuse of "free" Bits: In 2003, a proposal for an 
experimental RFC was published that wanted to reuse the high bits of 
the "fragment offset" part of the IP header for another purpose. No 
IANA consideration says how these bits can be repurposed, but the 
standard defines a specific meaning for them. The IESG concluded 
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that implementations of this experiment risked causing hard-to-debug 
interoperability problems and recommended not publishing the document 
in the RFC series. The RFC Editor accepted the recommendation. 


Note: in general, the IESG has no problem with rejected alternatives 
being made available to the community; such publications can be a 
valuable contribution to the technical literature. However, it is 
necessary to avoid confusion with the alternatives the working group 
did adopt. 


The RFC series is one of many available publication channels; this 
document takes no position on the question of which documents the RFC 
series is appropriate for. That is a matter for discussion in the 
IETF community. 


6. IAB Statement 


In its capacity as the body that approves the general policy followed 
by the RFC Editor (see RFC 2850 [3]), the IAB has reviewed this 
proposal and supports it as an operational change that is in line 
with the respective roles of the IESG and RFC Editor. The IAB 
continues to monitor the range of organized discussions within the 
IETF about potential adjustments to the IETF document publication 
processes (e.g., NEWTRK working group) and recognizes that the 
process described in this document, as well as other general IETF 
publication processes, may need to be adjusted in the light of the 
outcome of those discussions. 


7. Security Considerations 


The process change described in this memo has no direct bearing on 
the security of the Internet. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2004). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the IETF’s procedures with respect to rights in IETF Documents can 
be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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